This section is intended to introduce the reader to various aspects of art, which may be related to various aspects of the present invention that are described and/or claimed below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present invention. Accordingly, it should be understood that these statements are to be read in this light, and not as admissions of prior art.
Over the past few years the traditional TV broadcasting landscape of terrestrial, satellite and cable networks has been extended with the roll out of TV and video services over broadband internet protocol (IP) networks. These networks are complementary, with broadcast distribution adapted for live events and mass distribution and broadband distribution adapted for on-demand, catch-up and personalized services. Such a complementarity offers the perspective of a hybrid model in which the strengths of each network are leveraged to provide enhanced TV and video services in an efficient manner. Broadcast events can be enriched with personalized content delivered over broadband, this content being streamed or pushed beforehand. Such hybrid services may require that components delivered over the separate networks are tightly synchronized. One typical example illustrating this need of fine synchronization is a user watching a broadcast program who selects a foreign audio sequence that is not broadcasted but available over broadband. One other example is to enrich the broadcast content by delivering over broadband another video component, this last being for instance, according to the broadcast component, a scalable video coding (SVC) enhancement layer, a multi-view video coding (MVC) component to propose the event in 3D or another view of the same scene.
The ways to deliver this additional component over broadband are multiple. A first solution based on on-demand delivery is to use hypertext transfer protocol (HTTP) streaming, as described in the document “HTTP Live Streaming, draft-pantos-http-live-streaming-01—R. Pantos, Apple Inc Jun. 8, 2009” or to rely on the real-time transfer protocol (RTP) over UDP/IP as defined in the recommendation RFC 3550, “A Transport Protocol for Real-Time Applications”. In this last case a communication protocol as Real Time Streaming Protocol (RTSP), described in the recommendation RFC 2326 is associated to RTP. Another solution based on multicast delivery is to use RTP protocol (RTP/UDP/IP) as defined in the document “A Transport Protocol for Real-Time Applications”.
In the case of on demand delivery the request of the content can embed a timing information representing the presentation timestamp (PTS) of the first audiovisual sample to be delivered. It is not the case when the terminal subscribes to a multicast stream. The terminal cannot request it for a given timestamp and the behavior is analogous to the broadcast network one where the client suffers from the content delivery constraints.
Some characteristics for a network are its latency and its jitter. That means that it does not take the same duration to deliver content over one network and over another one.
The particularity of a broadcast network is that the content arrives to the receiver without it has to request anything, i.e. this last receives content permanently, and the delivery has a limited jitter that can be treated at the receiver with a limited size of buffer. The content delivery duration comprises the content delivery duration over the broadcast network from the server to the terminal and the duration the terminal needs to demultiplex, to buffer and to decode the content.
A broadband network can be seen as a personalized delivery network because it delivers content only on request of the receiver.
FIG. 1 illustrates the delivery of a program content over a broadband network. A video server delivers the program content to a set-top box receiver (STB). The set-top box receives and decodes the content in order to display it on a display device. The delivery can be split in four main steps and corresponding durations:                The duration the request needs to reach the server is T1.        The duration the server takes to treat the request and to emit the program content is T2.        The duration of the program content delivery from the server to the set-top box is T3.        The duration the set-top box needs to buffer, decode and display the program content is T4.        
The delivery in a hybrid broadcast broadband context does not necessarily imply that the time format is the same for all the components. In the MPEG-2 transport stream format (commonly used for broadcast networks), the timing information is based on a program clock reference (PCR) format whereas the network time protocol (NTP) is the format used for the timing of the stream encoded in the Real-Time Transport protocol (commonly used for broadband networks). Moreover, two components can have the same time format but the time references can differ (offset values). To compensate the mentioned timing issues between components, a mechanism must be implemented to transpose the timing format and/or reference in the ones of the other component. The timing format and/or reference of the component(s) delivered over broadband are lined up with the ones of the component(s) delivered over broadcast, this last being the “master” component. In the herein description, it is estimated that when timing formats and/or references are different this timing alignment operation is implicitly done to synchronize the components and when we evoke timing values they refer to timing values in the same transposed referential (same format and same initial value). This unique time referential is called system clock.
The component delivered over broadcast is called “main component” and the component delivered over broadband is called “personalized component”.
The method to deliver a personalized component is described here. The personalized component is requested by the terminal and is sent over a bidirectional broadband network. The delivery can be either linear or non linear.
A linear delivery ensures that the terminal receives a component at a quite constant rate. It can be not exactly constant due to the jitter network. Two cases can be considered for the delivery of a personalized component to be synchronized with a broadcasted main component. Either the personalized component stream can be received, decoded and presented before the corresponding frames of the main component are presented or it arrives after and in this case all the frames of the personalized component are useless.
The typical case of a linear delivery mechanism is when the terminal subscribes to a multicast stream by transmitting a request to join a multicast group as defined in the Internet Group Management Protocol (IGMP protocol). With a multicast stream deliver, the terminal cannot receive the stream from a defined timestamp. In this case, and if the personalized component arrives later than the corresponding frames of the main component, it is not possible to synchronize their rendering.
The real-time transfer protocol (RTP) is also well known for the linear delivery. RTP protocol allows the request of a content from a given timestamp which is equal to the current reception time reference plus an offset. The terminal estimates the offset in order to request the content in advance so as to receive the content before it needs to be decoded and rendered. If the offset is incorrectly evaluated, the personalized component is received too late to be synchronized with the main component. Consequently the client must stop the reception of the current streaming and it must evaluate more accurately the offset and then transmits a new request based on the new estimated offset value.
A non-linear delivery is a mechanism in which the terminal receives the content in a non regular way. A part of the content is delivered at a higher rate than it is presented. In example, the frame rate reception is higher than the frame rate presentation. The idea of the non linear delivery is to offer the possibility to a terminal receiving a personalized component that is first late to be presented to catch up the main component to be able to present it at a given moment.
A Real-Time Streaming Protocol (RTSP) server can also deliver content in a non-linear way. Depending on the request parameters, it can, for instance, deliver the first frames or group of pictures of a program content in a burst and then deliver the content at a cruising rate. In case of using RTSP, the terminal requests for a given presentation timestamp.
The Hyper Text Transfer Protocol (HTTP) streaming is another type of non linear delivery. The personalized component is split in many successive parts called chunks. A chunk is either a file or a part of a file including a piece of information describing it. The piece of information may comprise for example a time slot, a file name, a byte range, a bit-rate or any other information that may be useful for a terminal for decoding and rendering the chunk's content. The encoding of chunks containing video is starting with a key-frame which can be decoded without reference to a previous frame. The key-frame is for example an I-picture (or I-frame) as defined in MPEG compression standard (ISO/IEC13818). A chunk contains one or several full groups of pictures (GOPs) as defined in MPEG compression. When receiving content with the use of HTTP streaming, the terminal requests for a chunk to the server. The server then transmits the chunk with best effort. The content is transmitted into successive bursts.
The non-linear delivery offers the possibility to a terminal to synchronize the rendering of a personalized component to the rendering of a main component by sending successive requests in order to get some pieces of the personalized content, starting with a key-frame, that are synchronized with the main component in term of system clock, decoding time reference and presentation time reference.
A disadvantage of such a synchronization is that when a terminal requests for a personalized component to be synchronized with a main component and receives a content, starting with a key-frame, for which the decoding and presentation time reference indicate that the reception is too late to be synchronized with the main component, the discarded content may correspond to an important time range (up to many seconds) in term of rendering. The terminal has then to send one or more new requests and to receive new personalized stream content until the decoding and presentation time reference indicates that the synchronization is possible in the terminal.